8장. 모델을 우리 데이터로 가르치기

출처: 『RAG 마스터: 랭체인으로 완성하는 LLM 서비스』(브라이스 유·조경아·박수진·김재웅 지음, 프리렉 2025) | 원서 8장 대응 | 공식: www.langchain.com

코드는 분위기만 — LoraConfig·apply_chat_template·-100 같은 말은 몰라도 됩니다. 표의 '비유'와 '위험'만 봐도 충분해요.

이 장은 RAG를 한 단계 더 밀어붙인다.

지금까지는 문서를 찾아다 모델에게 보태 줬다(RAG).

이번엔 모델 자체를 우리 RAG 일에 맞게 다시 가르친다.

그게 0장에서 살짝 본 파인튜닝이다.

0. 이 장의 새 단어 (0장에 없는 말만)

0장 용어집은 이미 머리에 있다고 보고, 이 장에서 새로 나오는 말 3개만 여기서 풀어 둔다.

본문에서 막히면 이 칸으로 돌아오면 된다.

네거티브 샘플(negative sample)

한 문장 뜻 — 검색은 됐지만 질문의 답이 들어 있지 않은 엉뚱한 문서.

일상비유 — 시험 볼 때 책상에 펼쳐 둔 책 중 이 문제와 상관없는 페이지. 펼쳐는 놨지만 답은 없다.

한 줄 예 — "한글 만든 왕은?" 물었는데 '이순신' 문서가 같이 검색됨. 이 '이순신' 문서가 네거티브 샘플.

(반대로 답이 든 '세종대왕' 문서는 포지티브 샘플이다.)

생각의 사슬(CoT, chain of thought)

한 문장 뜻 — 답을 바로 쓰지 않고, 근거를 먼저 적은 뒤 답을 쓰게 하는 방식.

일상비유 — 수학 문제에서 답만 달랑 쓰지 않고 풀이 과정을 적는 것. 과정을 적으면 실수가 준다.

한 줄 예 — "##이유: 문서에 '세종대왕이 한글을 만들었다'고 적힘 ##답변: 세종대왕" 처럼 이유 먼저, 답 나중.

로라(LoRA, 저랭크 적응)

한 문장 뜻 — 거대한 모델 전체를 다시 가르치지 않고, 작은 부품만 덧붙여 그것만 가르치는 가벼운 방법.

일상비유 — 큰 기계를 통째로 뜯어고치지 않고, 작은 보조 장치 하나만 끼워 동작을 바꾸는 것. 싸고 빠르다.

한 줄 예 — 70억 개 숫자를 다 만지는 대신, 그 중 몇 줌만 골라 가르친다. GPU가 작아도 된다.

(귀납 도입) 이런 적 있죠?

RAG를 잘 만들어 놨다. 문서도 잘 찾아온다.

그런데 모델이 자꾸 엉뚱한 짓을 한다.

장면 하나 — 검색 결과에 상관없는 문서가 섞여 들어왔다.

"한글을 창제한 조선의 왕은?" 하고 물었더니, 검색기가 '장영실', '이순신', '이방원', '세종대왕' 네 문서를 가져왔다.

답은 '세종대왕' 문서에만 있다.

그런데 모델이 나머지 셋까지 끌어다 뒤죽박죽 답을 만든다.

장면 둘 — 답이 어디에도 없는데, 모델이 아는 척 지어낸다.

검색된 다섯 문서가 전부 질문과 무관하다.

모델은 "모르겠다"고 하지 않고, 자기 머릿속 기억으로 틀린 답을 술술 쓴다.

장면 셋 — 답은 맞는데, 어느 문서를 봤는지 안 알려 준다.

사용자는 그 답이 진짜인지 확인할 길이 없다.

이 세 장면의 공통점은 모델이 RAG에 맞는 습관을 안 배웠다는 것이다.

검색 결과를 고르고, 없으면 없다고 하고, 본 문서의 출처를 다는 습관.

이 습관을 모델에 직접 새겨 넣는 일이 이 장의 파인튜닝이다.

책의 한 장면을 미리 보면 이렇다.

# 아래 예제는 핵심 흐름만 짧게 보여 줍니다.
# 모델을 우리 RAG 데이터로 다시 가르치는 한 줄 (분위기만)
trainer.train()   # 약 30분 뒤, 출처 잘 다는 모델 완성

이 한 줄에 닿기까지, 데이터를 어떻게 만들고 모델을 어떻게 가르치는지 차근차근 본다.

이 장에서 딱 6가지만

네거티브 샘플 — 일부러 엉뚱한 문서를 섞어 가르쳐야, 모델이 그걸 무시하는 법을 배운다.

생각의 사슬(CoT) — 답 전에 근거를 먼저 쓰게 하면 헛소리가 준다.

답변 없음 데이터 — "답이 없으면 없다고 해"를 가르쳐야 지어내기를 막는다.

출처 인용 — [[ref3]]처럼 본 문서 번호를 달게 하면 믿을 수 있다.

5가지 데이터 유형 — 현실의 온갖 질문 상황을 골고루 담아야 실전에서 안 무너진다.

로라(LoRA) 파인튜닝 — 모델 전체가 아니라 작은 부품만 가르쳐 싸게 끝낸다.

학습 목표

네거티브 샘플과 포지티브 샘플을 구분한다.
생각의 사슬(CoT)이 왜 헛소리를 줄이는지 설명한다.
답변 없음 데이터와 출처 인용이 무엇을 막아 주는지 설명한다.
RAG 학습 데이터의 5가지 유형을 구분한다.
로라(LoRA)가 왜 가벼운 파인튜닝인지 설명한다.

1. 네거티브 샘플 — 일부러 엉뚱한 문서를 섞는다

망가지는 장면

검색기가 다섯 문서를 가져왔다.

답은 그 중 하나에만 있다.

모델은 나머지 넷에 휘둘려, 안 봐도 될 내용까지 끌어다 답을 더럽힌다.

처음부터 답이 든 깨끗한 문서만 보고 배운 모델이라, 노이즈에 약하다.

일상비유 (크게)

오픈북 시험인데, 책상에 펼친 책 다섯 권 중 한 권에만 답이 있다.

나머지 네 권은 이 문제와 상관없는 책.

평소 상관없는 책도 같이 펼쳐 놓고 연습한 학생은, 시험장에서 헷갈리는 책을 척척 넘긴다.

답 있는 페이지만 연습한 학생은, 엉뚱한 책에 코를 박고 헤맨다.

비유	코드	위험
상관없는 책도 섞어 연습	`documents = [장영실, 이순신, 세종대왕, 이방원]`	안 섞으면 노이즈에 약함
답 있는 책만 골라 보기	`is_oracle = True` (세종대왕 문서)	깨끗한 데이터만 배우면 실전서 무너짐

정의

네거티브 샘플은 검색은 됐지만 질문의 답이 없는 문서다.

포지티브 샘플은 답이 든 문서다(오라클 문서라고도 부른다).

학습 데이터에 네거티브 샘플을 일부러 넣어야, 모델이 그걸 무시하는 능력을 기른다.

이 아이디어가 RAFT라는 논문의 핵심이다.

사이드박스 — 이름의 뜻 (흥미용)

RAFT는 미국 버클리 대학이 2024년에 낸 논문이다. 원문: arxiv.org/abs/2403.10131.

이름은 "RAG를 위한 파인튜닝"이라는 뜻을 담았다. 외울 필요는 없다.

예시 폭격

예시 1 (완성예) — 질문과 검색 문서, 그리고 어느 게 정답인지 표시한 한 덩어리.

# 검색 결과에 답 있는 문서(오라클) + 엉뚱한 문서(네거티브)를 함께 담는다
# `sample`에 중간 결과를 담아 다음 줄에서 재사용합니다.
sample = {
    # 이 줄은 예제 흐름을 이루는 실제 처리 단계입니다.
    "question": "한글을 창제한 조선의 왕은?",
    # 검색이나 요약에 쓸 원본 문서를 읽어 옵니다.
    "documents": [
        {"text": "장영실은 조선의 과학자...", "정답인가": False},  # 네거티브
        {"text": "이순신은 임진왜란...",     "정답인가": False},  # 네거티브
        {"text": "세종대왕은 1443년 훈민정음...", "정답인가": True},  # 포지티브
    ],
}

예시 2 (부분완성 — 빈칸 채우기) — 아래에서 어느 줄이 네거티브일까?

# 검색된 문서 조각들을 담아 답변 근거로 씁니다.
docs = [
    "이방원은 조선 태종으로 즉위했다.",   # 한글 창제와 무관 → ____ 샘플
    "세종대왕이 훈민정음을 반포했다.",     # 답이 들어 있음   → ____ 샘플
]
# 빈칸: 첫 줄 = 네거티브, 둘째 줄 = 포지티브

예시 3 (독립적용) — "에펠탑 높이는?" 질문에 '에펠탑 야경 사진 안내', '에펠탑 320m', '파리 맛집' 세 문서가 왔다.

직접 골라 보자. 포지티브는 '에펠탑 320m' 하나, 나머지 둘은 네거티브다.

미니 시나리오

사내 규정 챗봇을 만든다.

학습 데이터에 규정 문서만 깔끔하게 넣었더니, 실제로는 회식 공지·메뉴판까지 섞여 검색돼 답이 엉켰다.

→ 이럴 땐 학습 데이터에 일부러 무관한 문서를 섞어 "이건 무시해" 연습을 시킨다.

2. 생각의 사슬(CoT) — 답 전에 근거를 먼저 쓴다

망가지는 장면

모델에게 답만 바로 쓰게 했다.

그랬더니 문서에 없는 내용인데도 그럴듯하게 지어낸다.

근거를 안 따지고 결론부터 던지니, 헛소리를 거를 장치가 없다.

일상비유 (크게)

수학 시험에서 답만 달랑 적는 학생과, 풀이 과정을 또박또박 적는 학생.

풀이를 적는 학생은 중간에 "어? 이 줄이 이상한데" 하고 스스로 잡아낸다.

답만 쓰면 틀린 줄도 모른다.

비유	코드	위험
풀이 과정 먼저 적기	`"##이유: ... ##답변: 델리"`	근거 없이 답하면 지어냄
원문 그대로 인용	`"##인용시작## 본사는 델리 ##인용종료##"`	원문 안 보면 헛소리

정의

생각의 사슬은 답을 쓰기 전에 근거(이유)를 먼저 쓰게 하는 방식이다.

RAFT는 한 발 더 나가, 근거를 쓸 때 원문 문장을 그대로 인용하게 강제한다.

##인용시작## 과 ##인용종료## 사이에는, 검색 문서에 진짜로 있는 문장만 넣어야 한다.

원문에 없는 문장은 못 넣으니, 자연히 헛소리가 줄어든다.

예시 폭격

예시 1 (완성예) — 책에 나온 실제 CoT 답변 형식.

# `cot_answer`에 중간 결과를 담아 다음 줄에서 재사용합니다.
cot_answer = """
##이유: 문서에서 ##인용시작## 오베로이 그룹은 본사가 델리에 있는 호텔 회사입니다. ##인용종료##
이 문장이 본사가 델리에 있음을 보여 준다.
##답변: 델리
"""

이유에서 원문을 그대로 인용한 뒤, 마지막에 답을 적었다.

예시 2 (부분완성) — 아래 빈칸엔 무엇이 들어갈까?

# 아래 예제는 핵심 흐름만 짧게 보여 줍니다.
# 형식: ##이유: (____ 인용 + 설명)  ##답변: (최종 답)
# 빈칸 = 검색 문서의 원문 문장

예시 3 (독립적용) — "물은 몇 도에서 끓나?" 문서에 "물은 100도에서 끓는다"가 있다.

CoT 형식으로 직접 써 보면: ##이유: ##인용시작## 물은 100도에서 끓는다 ##인용종료## ##답변: 100도.

미니 시나리오

고객 응대 봇이 환불 규정을 자꾸 지어냈다.

→ "답 전에 규정 원문을 먼저 인용하라"고 가르쳤더니, 규정에 없는 말은 못 하게 됐다.

3. 답변 없음 데이터 — 모르면 모른다고 가르친다

망가지는 장면

검색된 다섯 문서가 전부 엉뚱했다(전부 네거티브 샘플).

답이 어디에도 없다.

그런데 모델이 "모르겠다"고 안 하고, 머릿속 기억으로 틀린 답을 지어낸다.

이게 0장에서 본 그 지어내기(할루시네이션)다.

일상비유 (크게)

오픈북 시험인데, 책 어디를 펴 봐도 답이 없다.

성실한 학생은 "이 책엔 답이 없네요"라고 솔직히 쓴다.

허세 부리는 학생은 아무 말이나 지어내 답안지를 채운다.

비유	코드	위험
"이 책엔 답 없음" 솔직히	`answer = "검색 결과에 답이 없습니다."`	안 가르치면 지어냄
인용 문서 0개	`extracted_ref_numbers = []`	빈 답인데 출처 달면 거짓

정의

답변 없음 데이터는, 검색 결과에 답이 없을 때 "없다"고 답하도록 가르치는 학습 데이터다.

답변 칸에는 "검색 결과에는 해당 질문에 대한 내용이 없습니다" 같은 문장을 넣는다.

인용한 문서 번호는 빈 목록이다(아무 문서도 인용 안 함).

이걸 안 가르치면, 모델은 답이 없어도 무조건 뭔가 만들어내려다 헛소리를 한다.

예시 폭격

예시 1 (완성예) — 답변 없음 데이터 한 칸.

# `sample`에 중간 결과를 담아 다음 줄에서 재사용합니다.
sample = {
    # 이 줄은 예제 흐름을 이루는 실제 처리 단계입니다.
    "question": "원종 설립 당시 일본 정부의 반응은?",
    # 이 줄은 예제 흐름을 이루는 실제 처리 단계입니다.
    "answer": "검색 결과에는 원종 설립 당시 일본 정부의 반응을 찾을 수 없습니다.",
    "extracted_ref_numbers": [],   # 빈 목록 = 인용 문서 없음
}

예시 2 (부분완성) — 답이 없을 때 인용 목록은?

# 아래 예제는 핵심 흐름만 짧게 보여 줍니다.
# 답이 검색 결과에 없으면 extracted_ref_numbers = ____
# 빈칸 = []  (빈 목록)

예시 3 (독립적용) — "1500년 화성 날씨는?" 문서에 그런 정보가 없다.

직접 답을 써 보면: "검색 결과에는 1500년 화성 날씨에 대한 내용이 없습니다", 인용 목록은 [].

미니 시나리오

법률 상담 봇이, 관련 판례가 없는데도 가짜 판례를 지어내 큰일 날 뻔했다.

→ "없으면 없다고 해" 데이터를 잔뜩 넣어 가르쳤더니, 모르는 건 솔직히 모른다고 한다.

4. 출처 인용 — 본 문서 번호를 단다

망가지는 장면

모델이 답은 그럴듯하게 했다.

그런데 어느 문서를 보고 답했는지 안 알려 준다.

사용자는 그 답이 진짜인지 확인할 길이 없다.

일상비유 (크게)

리포트를 쓸 때 각주(출처)를 다는 것.

"이 주장은 3번 책 12쪽에서 봤다"고 적으면, 읽는 사람이 직접 펴 보고 확인한다.

각주가 없으면, 그게 사실인지 지어낸 건지 알 수가 없다.

비유	코드	위험
문장마다 각주 달기	`"...73.2%가 찬성했습니다 [[ref3]]"`	출처 없으면 검증 불가
여러 출처 함께	`"...영향을 미칩니다 [[ref1]], [[ref4]]"`	출처 빠뜨리면 신뢰 추락

정의

출처 인용은, 답변의 각 문장 뒤에 그 내용을 가져온 문서 번호를 [[ref3]] 형태로 다는 것이다.

여러 문서를 봤으면 [[ref1]], [[ref5]]처럼 모두 적는다.

출처를 달면 두 가지 이득이 있다.

하나, 사용자가 원문을 확인해 진위를 따질 수 있다.

둘, 모델 스스로 "이 문장 출처가 어디지?"를 따지며 답하니 헛소리가 준다.

예시 폭격

예시 1 (완성예) — 출처를 단 답변 한 토막.

# 파인튜닝된 모델의 답변 (출처 포함)
# `answer`에 중간 결과를 담아 다음 줄에서 재사용합니다.
answer = "2015년 조사에서 73.2%가 찬성했습니다 [[ref3]]."

예시 2 (부분완성) — 1번과 4번 문서를 동시에 봤다면?

# 아래 예제는 핵심 흐름만 짧게 보여 줍니다.
# "...강남 부동산에 큰 영향을 줍니다 ____"
# 빈칸 = [[ref1]], [[ref4]]

예시 3 (독립적용) — 답을 2번 문서에서 가져왔다면, 문장 끝에 [[ref2]]를 직접 붙이면 된다.

미니 시나리오

설문 결과를 정리해 주는 봇이, 숫자는 맞는데 출처가 없어 사용자가 못 믿었다.

→ "문장마다 본 문서 번호를 달라"고 가르쳤더니, 누구나 원문을 펴 확인하게 됐다.

5. 5가지 데이터 유형 — 현실의 온갖 질문을 골고루 담는다

망가지는 장면

학습 데이터를 한 가지 모양으로만 만들었다.

전부 "누구인가요?" 같은 완성된 문장 질문, 검색 결과는 항상 5개.

그랬더니 실전에서 검색 결과가 3개만 오거나, 질문이 명사구("송파구청장 합격 연도")로 오면 성능이 뚝 떨어진다.

연습 안 한 상황은 다 못 푼다.

일상비유 (크게)

운전 연습을 맑은 날 직선 도로에서만 했다.

실제 도로엔 비도 오고, 골목도 있고, 갑자기 끼어드는 차도 있다.

다양한 상황을 골고루 연습해야 실전에서 안 당황한다.

비유	코드	위험
온갖 도로 골고루 연습	`type` 5종을 학습에 모두 포함	한 유형만 배우면 실전서 무너짐
비·골목·끼어들기 대비	`no_answer`, `paraphrased_question` 등	한 상황만 연습하면 다른 상황서 실패

정의

책이 쓰는 학습 데이터(klue-mrc-ko-rag-dataset)에는 질문 상황을 5가지 유형으로 나눠 담았다.

각 유형은 현실에서 벌어질 서로 다른 상황에 대비한다.

유형	어떤 상황인가
`mrc_question`	장소·이름·날짜를 묻는 지엽적 질문. 검색 결과 항상 5개
`mrc_question_with_1_to_4_negative`	같은 지엽적 질문인데, 검색 결과가 1~4개만 오는 경우
`paraphrased_question`	지엽적 질문이지만 명사구 형태("…합격 연도")
`synthetic_question`	포괄적 질문. 답이 길고 여러 문서를 동시 인용
`no_answer`	검색 결과에 답이 없는 경우. "없습니다"로 답함

이 5종을 골고루 넣어야, 실전의 다양한 상황에서 성능이 안 떨어진다.

예시 폭격

예시 1 (완성예) — 데이터에 어떤 유형이 있는지 들여다보기.

# 필요한 라이브러리나 클래스를 가져와서 아래 예제에서 쓸 준비를 합니다.
from datasets import load_dataset
# `dataset`에 중간 결과를 담아 다음 줄에서 재사용합니다.
dataset = load_dataset("iamjoon/klue-mrc-ko-rag-dataset")
# 모델을 조금 더 가르치거나 학습 설정을 준비합니다.
df = dataset["train"].to_pandas()
# 중간 결과를 눈으로 확인해 흐름이 맞는지 봅니다.
print(df["type"].unique())
# → mrc_question, mrc_question_with_1_to_4_negative,
#    paraphrased_question, synthetic_question, no_answer

예시 2 (부분완성) — 다음 질문은 어느 유형일까?

# 아래 예제는 핵심 흐름만 짧게 보여 줍니다.
# "한국전력 본사 부지 매각이 강남에 미칠 영향은?"  → 답이 길고 여러 문서 인용
# 빈칸 = synthetic_question (포괄적 질문)

예시 3 (독립적용) — "송파구청장이 사시에 합격한 연도" 라는 질문.

문장이 아니라 명사구로 끝난다. 직접 골라 보면 paraphrased_question이다.

미니 시나리오

검색 결과가 늘 5개라고 가정하고 가르쳤더니, 실제로 2개만 검색된 날 모델이 멍해졌다.

→ 검색 결과가 1~4개인 경우(mrc_question_with_1_to_4_negative)도 섞어 가르치니 해결됐다.

한 걸음 더 ▸ (지금 몰라도 됨)

데이터를 학습용과 시험용으로 나눌 때, 유형별로 같은 비율을 지킨다.

그냥 마구 나누면 no_answer 유형이 학습 쪽에서 통째로 빠질 수 있다. 그러면 "모른다고 답하기"를 영영 못 배운다.

지금은 "골고루 나눈다"만 들고 가면 충분하다.

6. 로라(LoRA) 파인튜닝 — 모델 전체가 아니라 작은 부품만 가르친다

망가지는 장면

70억 개 숫자로 된 거대한 모델을 통째로 다시 가르치려 했다.

그랬더니 GPU 메모리가 폭발하고, 시간도 한참 걸린다.

개인이나 작은 팀은 엄두도 못 낸다.

일상비유 (크게)

거대한 공장 기계의 동작을 바꾸고 싶다.

기계 전체를 뜯어 부품을 다 갈면 돈도 시간도 어마어마하다.

대신 작은 보조 장치 하나만 끼워서 동작을 바꾸면 싸고 빠르다.

LoRA가 바로 그 작은 보조 장치다.

비유	코드	위험
작은 보조 장치만 끼움	`r=16` (작은 부품 크기)	통째 수정하면 GPU 폭발
기계 본체는 그대로	`target_modules=["q_proj", "v_proj"]`	부품 너무 작으면 효과 미미

정의

파인튜닝(0장 용어)은 모델 자체를 우리 데이터로 다시 가르치는 일이다.

문제는, 큰 모델 전체를 가르치면(풀 파인튜닝) GPU와 시간이 엄청 든다.

로라(LoRA)는 모델 본체는 그대로 두고, 작은 보조 부품만 덧붙여 그 부품만 가르친다.

가르칠 숫자가 확 줄어드니, 빠르고 GPU도 적게 쓴다.

예시 폭격

예시 1 (완성예) — LoRA 설정 한 덩어리(값은 분위기만).

# 필요한 라이브러리나 클래스를 가져와서 아래 예제에서 쓸 준비를 합니다.
from peft import LoraConfig
# 모델을 조금 더 가르치거나 학습 설정을 준비합니다.
peft_config = LoraConfig(
    r=16,                       # 보조 부품의 크기 (클수록 표현력↑ 메모리↑)
    lora_alpha=32,              # 학습 강도 (클수록 더 세게 반영)
    target_modules=["q_proj", "v_proj"],  # 모델의 일부에만 적용
    task_type="CAUSAL_LM",      # 다음 단어를 예측하는 모델
)

예시 2 (부분완성) — 메모리를 더 아끼려면 r 값을?

# 아래 예제는 핵심 흐름만 짧게 보여 줍니다.
# r = 64  → 더 넓게 가르침 (메모리↑)
# r = ___ → 더 좁게 가르침 (메모리↓)
# 빈칸 = 2 같은 작은 값

예시 3 (독립적용) — GPU가 아주 작다면, r을 작게 잡아 가르칠 양을 줄이면 된다. 대신 효과는 조금 약해진다.

미니 시나리오

노트북 한 대로 큰 모델을 파인튜닝하려다 메모리 부족으로 멈췄다.

→ 통째 학습 대신 LoRA로 작은 부품만 가르치니, 빌린 GPU 하나로 30분 만에 끝났다.

한 걸음 더 ▸ (지금 몰라도 됨)

모델을 가르칠 때는 텍스트를 숫자 묶음으로 바꾼다(0장 토큰 칸 참고).

이때 모델이 답해야 할 부분만 골라 가르치고, 시스템 지시문이나 사용자 질문은 가르치지 않는다.

책은 가르치지 않을 자리에 -100이라는 표시를 박아 둔다. 채점에서 빼라는 뜻이다.

비유하면 시험지 전체 중 정답 칸만 채점하고, 문제 칸은 채점 안 하는 것이다. 지금은 "답 부분만 가르친다"만 알면 된다.

단순 규칙 (이것만 외우면 됨)

학습 데이터엔 엉뚱한 문서(네거티브 샘플)를 일부러 섞는다 → 무시하는 법을 배운다.
답 전에 근거(CoT)를 먼저, 그것도 원문 인용으로 쓰게 한다 → 헛소리가 준다.
답이 없으면 "없다"고 답하게 가르친다 → 지어내기를 막는다.
문장마다 본 문서 번호 [[ref3]]를 단다 → 믿을 수 있다.
현실의 질문 상황을 5가지 유형으로 골고루 담는다 → 실전서 안 무너진다.
모델 전체 말고 작은 부품(LoRA)만 가르친다 → 싸고 빠르다.

한 줄로 — 엉뚱한 문서·근거·없음·출처를 골고루 가르치면, RAG 모델이 똑똑해진다. 그것도 LoRA로 가볍게.

더 해보기

검증된 실습·공식 자료(생존 확인 2026-05-21). 책에는 클릭 링크가 없어 여기 모았다.

책 공식 실습 노트북(코랩) — Ch08. Fine-tuning for RAG (데이터 만들기 + Qwen 파인튜닝)
RAFT 논문(버클리, 2024) — arxiv.org/abs/2403.10131 (네거티브 샘플 + CoT의 원조)
실습 데이터셋 — klue-mrc-ko-rag-dataset (한국어 RAG 학습 데이터)
로라(LoRA) 개념 문서 — huggingface.co/docs/peft (작은 부품만 가르치는 원리)
빌리는 GPU, 런팟 — runpod.io (실습용 클라우드 GPU. 끝나면 꼭 끄기)

정리

RAG를 한 단계 더 밀어붙이는 길은 모델 자체를 RAG 일에 맞게 다시 가르치는 것이다.

엉뚱한 문서를 섞고, 근거를 먼저 쓰게 하고, 없으면 없다 하게 하고, 출처를 달게 한다.

이 습관을 5가지 상황에 골고루 담아, LoRA로 가볍게 가르치면 모델이 RAG에 강해진다.

다음 마지막 장에서는 이 책에서 배운 것들을 묶어 마무리한다. 지금은 8장의 여섯 가지만 머리에 있으면 충분하다.

연습문제

설명. 모델을 우리 데이터로 가르치기의 핵심을 처음 듣는 사람에게 한 문장으로 설명하라.
구분. 두 개념(RAG, 파인튜닝)을 실제 예시 하나로 구분하라.
적용. 내 프로젝트나 학습 노트에서 이 장의 개념을 적용해 작게 개선할 지점을 하나 고르라.

부록 A. 쉬운 용어 사전

용어	아주 쉬운 뜻	이 장에서 나온 위치
RAG	답변할 때 관련 자료를 찾아 붙여 모델이 근거를 보고 답하게 하는 방식.	부록 B와 본문 예시
파인튜닝	이미 학습된 모델에 새 예시를 더 보여 주어 특정 행동을 더 잘하게 만드는 작업.	부록 B와 본문 예시
LoRA	모델 전체가 아니라 작은 추가 부품만 학습해 비용을 줄이는 파인튜닝 방식.	부록 B와 본문 예시
전체 파인튜닝	모델의 많은 가중치를 직접 바꾸며 다시 학습하는 방식.	부록 B와 본문 예시

부록 B. 헷갈리는 개념 비교표

A	B	구분 포인트
RAG	파인튜닝	RAG는 답변 때 자료를 붙이고, 파인튜닝은 모델 행동 자체를 조금 바꾼다.
LoRA	전체 파인튜닝	LoRA는 작은 부품만 학습하고, 전체 파인튜닝은 모델 전체를 크게 건드린다.

부록 C. 더 읽을 자료

이 장의 더 해보기 섹션 — 이미 모아 둔 공식 문서나 실습 링크가 있으면 여기서 먼저 확인한다.
같은 책의 0장 한눈에 보기 — 용어가 막히면 0장의 용어집과 개념 척추로 돌아간다.
원본 딥다이브판 같은 장 — 입문판을 읽고 큰 흐름이 잡힌 뒤 세부 논리를 더 깊게 확인한다.
이 장의 flashcards.json — 읽은 직후 질문만 보고 답을 떠올리는 회상 연습에 쓴다.

부록 D. 연습문제 풀이

설명 예시. 모델을 우리 데이터로 가르치기는 RAG에서 자료를 더 잘 찾고, 근거를 더 안전하게 붙이고, 답변 흐름을 더 다루기 쉽게 만드는 방법을 보는 장이다. 중요한 것은 용어를 외우는 것이 아니라, 이 개념이 어떤 입력·부품·결정에 영향을 주는지 말로 풀어 보는 것이다.
구분 예시. 두 개념(RAG, 파인튜닝)의 차이는 이렇게 잡으면 된다. RAG는 답변 때 자료를 붙이고, 파인튜닝은 모델 행동 자체를 조금 바꾼다. 실제 사례를 볼 때는 목적, 입력, 실패했을 때의 증상을 따로 적어 보면 헷갈리지 않는다.
적용 예시. 가장 작은 개선부터 고른다. 예를 들어 이름을 더 분명히 하거나, 평가 기준을 한 줄 추가하거나, 직접 알 필요 없는 내부 정보를 감추는 식으로 시작한다. 한 번에 크게 갈아엎는 것보다 작은 변경 하나를 확인하며 진행하는 쪽이 입문 단계에 맞다.

질문

카드를 로딩 중...

답변

클릭하거나 Space를 눌러 뒤집기

0 / 0

학습 진도 0%

← → 이동 Space 뒤집기 R 셔플